home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000159_news@columbia.edu _Fri Dec 29 13:12:36 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by monire.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA18333
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 29 Dec 2000 13:12:35 -0500 (EST)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA24179
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Dec 2000 13:12:35 -0500 (EST)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id NAA08497
  10.     for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Dec 2000 13:10:44 -0500 (EST)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: fdc@columbia.edu (Frank da Cruz)
  13. Subject: Re: Converting struct tm to time_t
  14. Date: 29 Dec 2000 18:10:43 GMT
  15. Organization: Columbia University
  16. Message-ID: <92ik33$89f$1@newsmaster.cc.columbia.edu>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In article <ylito3uonk.fsf@windlord.stanford.edu>,
  20. Russ Allbery  <rra@stanford.edu> wrote:
  21. : INN currently uses [the following], which seems to work fairly well.  I'm
  22. : the author of this code; you can consider it to be in the public domain.
  23. : Note that this code requires that time_t be an arithmetic type, which may
  24. : not work properly on some non-UNIX platforms (it could presumably be
  25. : replaced by a long or something).
  26. : 
  27. Thanks.  Yes, I always knew I could do the day/month/year/time arithmetic
  28. myself, and already do this kind of thing in other parts of the Kermit code,
  29. but not for interfacing with system APIs, e.g. see:
  30.  
  31.   http://www.columbia.edu/kermit/case17.html
  32.  
  33. As you say, your code does presume a few things about what time_t is:
  34.  
  35.  . An integer (in the mathematical sense), unsigned.
  36.  . The number of seconds since 1 Jan 1970 0:00:00.
  37.  
  38. If that is always true, fine.  Of course the whole purpose of having, and
  39. making us use, fabrications like time_t is to hide all that from us.  Who
  40. knows what our UNIX vendors will come up with as we approach the 2038 barrier
  41. that will break these assumptions.
  42.  
  43. Anyway, I suppose it's worth a shot.  In the meantime, too bad whoever
  44. thought of mktime() didn't make it do just one thing (in the UNIX spirit),
  45. instead of two things at once, without allowing those things to be done
  46. separately.
  47.  
  48. Another solution that had occurred to me was to compare the localtime() and
  49. gmtime() results for the same clock time, figure out the GMT/UTC offset, and
  50. deduct it to the target struct tm before passing it to mktime(), but gmtime()
  51. and localtime() are not among the most portable of UNIX APIs, plus I don't
  52. know how consistent their semantics are across platforms, e.g. if you give
  53. them a seconds or minutes field greater than 60 or less than 0, etc.
  54.  
  55. Thanks again.
  56.  
  57. - Frank